home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / inet / ietf / snmpsec / 91jul.min next >
Text File  |  1993-02-17  |  9KB  |  220 lines

  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4.  
  5. Reported by James Galvin/TIS and Keith McCloghrie/Hughes
  6.  
  7. SNMPSEC Minutes
  8.  
  9. Status of the Documents Reviewed:
  10.  
  11.    o All three:  the SNMP Administrative Framework, SNMP Security
  12.      Protocols, and SNMP Party MIB, were published as Internet Drafts
  13.      immediately after the previous IETF (in St.  Louis).
  14.  
  15.    o An update to the SNMP Party MIB was distributed to the snmp-sec-dev
  16.      mailing-list at the beginning of July.
  17.  
  18.  
  19. The Outstanding Issues were Discussed:
  20.  
  21.  
  22.    o Mike St.Johns suggested consideration of the use of ``threshold
  23.      keying'', in the distribution of initial secrets.  Threshold keying
  24.      is a standard security technique (see Denning's book on Computer
  25.      Security), in which the keys are split into multiple ``shadow''
  26.      parts.  The parts could be distributed separately and then
  27.      recombined to obtain the initial secret.  Use of this technique
  28.      would allow an administration to, for example, have a single shadow
  29.      key which would be manually entered into each agent at install
  30.      time, and another shadow key calculated by the nms so as to be
  31.      agent-specific and distributed to the agent; these two parts could
  32.      then be combined to get the initial secret.  The advantages would
  33.      be the ability to have the manually distributed secret information
  34.      be a) the same for all agents, and b) different from the secret
  35.      used as the initial key.  The disadvantage being the special
  36.      first-time-only processing the agent would need to recombine the
  37.      keys.  The meeting agreed to consider the suggestion in parallel
  38.      with other activities.
  39.  
  40.    o The differences between MD4 and MD5 were discussed, and the pros
  41.      and cons of using each.  A suggestion was made to update the text
  42.      of the SNMP Security Protocols document to replace occurrences of
  43.      ``SNMP MD4 Authentication Protocol`` by ``SNMP Digest
  44.      Authentication Protocol'' in discussions of all parts of the
  45.      protocol except the particular digest algorithm used, where the use
  46.      of ``MD4'' would be retained.  This suggestion was accepted since
  47.      it would minimize the text (e.g.  to one page) which would be
  48.      needed in a future memo specifying alternative digest algorithms.
  49.  
  50.    o A question on ``wildcard'' parties (analogous to the ``public''
  51.      community) was answered by discussing the ``initial'' noAuth,noPriv
  52.      parties defined by convention in the Party MIB. A lively discussion
  53.      ensued on the access rights to be afforded to this out-of-the-box
  54.      noAuth,noPriv party.  Some argued for allowing read-access to
  55.  
  56.                                    1
  57.  
  58.  
  59.  
  60.  
  61.  
  62.      everything in the MIB (except SNMP security's secret information);
  63.      others for allowing read-access to nothing, or just to MIB-II's
  64.      system group.  The consensus of the discussion seemed to be for
  65.      this working group to stay silent on the issue, and let the various
  66.      Requirements working groups make device-type specific
  67.      recommendations.  The Router Requirements WG. is making such a
  68.      recommendation for use of ``public'' communities, and knows it will
  69.      have to update that recommendation as and when the SNMP Security
  70.      documents are further along.
  71.  
  72.    o A discussion was held on the protocol's use of ASN.1 tags instead
  73.      of a version number field.  The same conclusion was reached as in
  74.      previous discussions of the same topic.
  75.  
  76.    o The term ``random values'' in the section of the SNMP Security
  77.      Protocols document discussing what to do when an agent loses its
  78.      knowledge of a secret, was clarified as being the need to set the
  79.      values to non-valid or non-guessable values.
  80.  
  81.  
  82.  
  83. There was discussion of the implementation experience gained so far:
  84.  
  85.  
  86.    o Three separate implementations were in various stages of
  87.      incompletion, and one other person had spent some preparing for an
  88.      implementation.  Two of these implementations interoperated with
  89.      each other using noAuth,noPriv.  Two had implemented MD4.  One was
  90.      using DES but was unsure that the encrypted data was correct.  To
  91.      date, there is no experience with multiple MIB views, proxy, clock
  92.      synchronization, nor SNMP access to the Party MIB.
  93.  
  94.    o A couple of ASN.1 definitions were discussed for possible
  95.      optimizations:
  96.  
  97.       -  The replacement of ANY by a CHOICE in types of AuthInformation,
  98.  
  99.       -  The specification of a fixed length for the OCTET STRING
  100.          containing the digest value, and
  101.  
  102.       -  The rearrangement of the authentication information and the
  103.          source/destination party fields leading to the removal of one
  104.          of the levels of serialization.
  105.  
  106.  
  107.      There was also discussion of the present access-control
  108.      granularity, and its ability to scale.  The definition of MIB
  109.      subviews does allow access control on individual instances, but at
  110.      the cost of entering each object instance in the View Table.  There
  111.      is a legitimate requirement to support several Views each
  112.      containing all the variables in, for example, the ifTable for just
  113.      one interface.  This requires a large number of entries in the View
  114.  
  115.                                    2
  116.  
  117.  
  118.  
  119.  
  120.  
  121.      Table even with only a moderate numbers of interfaces.
  122.  
  123.      The document editors agreed to update the documents to reflect the
  124.      (minor) changes resulting from the above discussions.  These
  125.      updates are expected to be available by the end of August.
  126.  
  127.      Finally, there was discussion of where to go next.  The general
  128.      consensus of the meeting was that SNMP Security was too important
  129.      and central to the technology for us to recommend progression in
  130.      the standards track with the present incomplete levels of
  131.      implementation experience.  When asked how many other
  132.      implementation efforts were planned for the near future, a half a
  133.      dozen attendees raised their hands.  These and others were strongly
  134.      encouraged to proceed with these implementations in order to gain
  135.      the required experience.  Interoperability testing of such
  136.      implementations across the Internet, and at the Interop '91
  137.      SNMP-demo ``staging'' event were discussed and encouraged.
  138.  
  139.  
  140. Attendees
  141.  
  142. Steve Alexander          stevea@i88.isc.com
  143. Karl Auerbach            karl@eng.sun.com
  144. Doug Barlow              barlow@decwet.dec.com
  145. James Barnes             barnes@xylogics.com
  146. Steve Bostock            steveb@novell.com
  147. Howard Brown             brown@ctron.com
  148. Theodore Brunner         tob@thumper.bellcore.com
  149. John Burruss             jburruss@wellfleet.com
  150. Jeffrey Case             case@cs.utk.edu
  151. Gigi Chu                 gigic@hpspd.spd.hp.com
  152. John Cook                cook@chipcom.com
  153. Tracy Cox                tacox@sabre.bellcore.com
  154. Emil Datability
  155. James Davin              jrd@ptt.lcs.mit.edu
  156. Jeffrey Edelheit         edelheit@mitre.org
  157. Gary Ellis               garye@hpspd.spd.hp.com
  158. Bill Fardy               fardy@ctron.com
  159. Barbara Fraser           byf@cert.sei.cmu.edu
  160. Jeff Fried               jmf@relay.proteon.com
  161. Deborah Futcher          dfutche@eco.twg.com
  162. Maria Gallagher          maria@nsipo.arc.nasa.gov
  163. Shawn Gallagher          gallagher@quiver.enet.dec.com
  164. James Galvin             galvin@tis.com
  165. Ron Jacoby               rj@sgi.com
  166. Mike Janson              mjanson@mot.com
  167. Frank Kastenholz         kasten@europa.clearpoint.com
  168. Manu Kaycee              kaycee@trlian.enet.dec.com
  169. Mark Kepke               mak@hpcndk.cnd.hp.com
  170. Kenneth Key              key@cs.utk.edu
  171. Christopher Kolb         kolb@psi.com
  172. Deidre Kostick           dck2@sabre.bellcore.com
  173. Bobby Krupczak           rdk@cc.gatech.edu
  174.  
  175.                                    3
  176.  
  177.  
  178.  
  179.  
  180.  
  181. Cheryl Krupczak          cheryl@cc.gatech.edu
  182. Nik Langrind             nik@shiva.com
  183. Anthony Lauck            lauck@tl.enet.dec.com
  184. Tim Lee-Thorp            ngc!tim@uunet.uu.net
  185. Ron Mackey               rem@dsiinc.com
  186. Keith McCloghrie         kzm@hls.com
  187. Evan McGinnis            bem@3com.com
  188. Lynn Monsanto            monsanto@eng.sun.com
  189. Bradford Parker          brad@cayman.com
  190. David Perkins            dperkins@synoptics.com
  191. John Pickens             jrp@3com.com
  192. Brian Price              brian@bss.com
  193. Anil Rijsinghani         anil@levers.enet.dec.com
  194. Kary Robertson           kr@concord.com.kr
  195. Jonathan Saperia         saperia@tcpjon.enet.dec.com
  196. Mark Schaefer            schaefer@davidsys.com
  197. John Seligson            johns@ultra.com
  198. Ron Sharp                rls@neptune.att.com
  199. Anil Singhal             nsinghal@hawk.ulowell.edu
  200. Mark Sleeper             mws@sparta.com
  201. Michael St.  Johns       stjohns@umd5.umd.edu
  202. Bob Stewart              rlstewart@eng.xyplex.com
  203. Bruce Taber              taber@interlan.com
  204. Ronald Tencati           tencati@nssdca.gsfc.nasa.gov
  205. Glenn Trewitt            trewitt@nsl.dec.com
  206. Theodore Tso             tytso@mit.edu
  207. William Versteeg         bvs@nrc.com
  208. David Waitzman           djw@bbn.com
  209. Steven Waldbusser        waldbusser@andrew.cmu.edu
  210. Drew Wansley             dwansley@secola.columbia.ncr.com
  211. David Ward               dward@chipcom.com
  212. Mark Wood                markl@dsiinc.com
  213. Brian Yasaki             bky@eco.twg.com
  214. Jeff Young               jsy@cray.com
  215. Joseph Zur               fibrontics!zur@uunet.uu.net
  216.  
  217.  
  218.  
  219.                                    4
  220.